On-board diagnostics (“OBD”) systems allow a vehicle owner or technician to access vital information about the various modules and sub-systems within the vehicle. For many years, manufacturers have included complex OBD systems in their vehicles. Such OBD systems are typically accessible through a data link connector (“DLC”) located under the dash of the vehicle. In a traditional repair setting, a technician utilizes a specialized scan tool that is adapted to interface with a given vehicle's OBD system over the vehicle's DLC. The scan tool is capable of reading data from the vehicle's sub-system for diagnostic purposes while also permitting the reprogramming of the sub-systems as desired. Typically these scan tools are stand-alone handheld computing devices, but there are some personal computer-based scan tools known in the art.
The first OBD systems, now known as OBD-I, were initially implemented to monitor a vehicle's emission control system for regulatory purposes. However, OBD-I was largely unsuccessful due to the lack of standardization of the OBD's placement within the vehicle, DLC configuration, and data format.
In response to the problems associated with OBD-I, OBD-II was developed. OBD-II presented a substantial improvement over OBD-I in both capability and standardization. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signaling protocols available, and messaging format. OBD-II also provides a candidate list of vehicle parameters to program, along with how to encode the data for each. OBD-II also introduced a standardized DLC—the female 16-pin (2×8) J1962 connector, as show in FIG. 1. Unlike the OBD-I connector, which was sometimes found under the hood of the vehicle, the OBD-II connector is required to be within 2 feet (0.61 m) of the steering wheel, and therefore is usually located under the dashboard. OBD-II also provided for a pin in the connector that provides power to the scan tool from the vehicle's battery, eliminating the need to connect a scan tool to a separate power source. Finally, the OBD-II standard provided an extensive list of standardized diagnostic trouble codes.
SAE J1962 defines the location of the OBD connector (i.e. within 2 feet of the steering wheel) and the pinout configuration thereof, as follows:                1. Manufacturer discretion.        2. Bus positive Line (for SAE-J1850 PWM and SAE-1850 VPW protocols)        3. Ford DCL(+) Argentina, Brazil (pre OBD-II) 1997-2000, USA, Europe, etc. Chrysler CCD Bus(+)        4. Chassis ground        5. Signal ground        6. CAN high (for ISO 15765-4 and SAE-J2284 protocols)        7. K line (for ISO 9141-2 and ISO 14230-4)        8. -        9. -        10. Bus negative Line (for SAE-J1850 PWM protocol)        11. Ford DCL(−) Argentina, Brazil (pre OBD-II) 1997-2000, Usa, Europe, etc. Chrysler CCD Bus(−)        12. -        13. -        14. CAN low (for ISO 15765-4 and SAE-J2284 protocols)        15. L line (for ISO 9141-2 and ISO 14230-4 protocols)        16. Battery voltage        
Although OBD-II provided some advantageous standardization across many vehicle manufacturers, the manufacturers still chose to employ different communication protocols, i.e. signal formats, for their particular OBD systems. Such protocols include, for example SAE J1850 PWM, SAE VPM, ISO 9141-2, ISO 14230, and ISO 15765. Each of these protocols varies in pinout configuration and signal characteristics.
For example, SAE J1850 PWM (pulse-width modulation—41.6 kB/sec, standard of the Ford Motor Company) has the following characteristics                pin 2: Bus+        pin 10: Bus−        High voltage is +5 V        Message length is restricted to 12 bytes, including CRC        Employs a multi-master arbitration scheme called ‘Carrier Sense Multiple Access with Non-Destructive Arbitration’ (CSMA/NDA)        
SAE J1850 VPW (variable pulse width—10.4/41.6 kB/sec, standard of General Motors) has the following characteristics:                pin 2: Bus+        Bus idles low        High voltage is +7 V        Decision point is +3.5 V        Message length is restricted to 12 bytes, including CRC        Employs CSMA/NDA        
The ISO 9141-2 protocol has an asynchronous serial data rate of 10.4 kBaud and is primarily used in Chrysler, European, and Asian vehicles. It has the following characteristics:                pin 7: K-line        pin 15: L-line (optional)        UART signaling (though not RS-232 voltage levels)        K-line idles high        High voltage is Vbatt        Message length is restricted to 12 bytes, including CRC        
ISO 14230 KWP2000 (Keyword Protocol 2000) has the following characteristics:                pin 7: K-line        pin 15: L-line (optional)        Physical layer identical to ISO 9141-2        Data rate 1.2 to 10.4 kBaud        Message may contain up to 255 bytes in the data field        
The ISO 15765 CAN (controller area network vehicle bus) (250 kBit/s or 500 kBit/s) protocol is a popular standard outside of the US automotive industry and is making significant gains into the OBD-II market share. As of 2008, all vehicles sold in the US are required to implement CAN, thus eliminating the ambiguity of the existing five signaling protocols.                pin 6: CAN High        pin 14: CAN Low        
Accordingly, because of the varying communication protocols, it is often necessary for a technician to purchase several different scan tools, each compatible with a particular OBD-II signal protocol. For example, a technician may need one scan tool for cars manufactured by the Ford Motor Company, and another scan tool for cars manufactured by General Motors. Thus, if a technician wishes to service a wide variety of vehicle makes and models, he often will have to make a substantial investment in scan tools. Moreover, because most scan tools are handheld devices that connect directly to a vehicle's DLC, the technician must carry out service directly next to, or inside of, the vehicle itself, which may be cumbersome or unsafe in a typical “garage” environment.
Moreover, there are typically two types of scan tools known in the art. A typical “aftermarket” scan tool has limited capability, only being capable of interfacing with certain modules and sub-systems, such as the engine control module and transmission control module, for purposes of maintaining proper fuel efficiency and emissions. Often, these aftermarket scan tools are limited to interfacing with those systems as dictated by SAE J2534. These aftermarket scan tools generally do not have the ability to read, analyze, manipulate, and reprogram the numerous other vehicle modules and sub-systems discussed below. A manufacturer-specific scan tool, on the other hand, is a scan tool designed to interface with all of the modules and sub-systems found within a vehicle and provides the ability to read, analyze, manipulate, program and reprogram such modules and sub-systems. Of course, the manufacturer-specific scan tools are much more expensive to own and maintain than the limited aftermarket scan tools. For one, the scan tool hardware itself is more expensive, but more importantly, the manufacturer-specific scan tools require daily, weekly, or monthly software updates in order to take advantage of the latest programming software. Accordingly, if a technician wishes to offer a full range of services for a particular vehicle manufacturer, he will have to purchase the expensive manufacturer-specific scan tool and a subscription so that he can obtain the latest software updates.
Various systems and methods for interfacing with a vehicle's OBD system are known in the art:
For example, U.S. Pat. No. 6,956,501 to Kitson describes an improved vehicle monitoring system for measuring the performance of the vehicle, including a wireless communication link for transmitting vehicle information to a terminal proximate to the vehicle, i.e. at a fuel station. The local terminal processes the information and communicates it to the operator of the vehicle through a display or other means. The system described in Kitson, however, is undesirable for at least two reasons. First, the system is only adapted for diagnostics and monitoring, i.e. “reading” data, and is not sufficient for vehicle programming, i.e. altering vehicle sub-systems. Second, Kitson only allows the transmission of vehicle data to a location proximate, i.e. next to, the vehicle. Kitson fails to provide for a system or method that enables a technician to program a vehicle's systems from a location substantially remote from the location of the vehicle.
U.S. Pat. No. 7,519,458 to Buckley describes a system, apparatus and method for obtaining and analyzing select vehicle data obtained from a vehicle. The system includes an interface communicatively coupled to the vehicle that obtains vehicle data associated with the operation of the vehicle. The system then communicates with a remote node via a network in order to obtain the necessary information to properly analyze the vehicle data. Once it has obtained the necessary information, the vehicle data is analyzed for diagnostic and monitoring purposes. Buckley, however, fails to provide for a system that is capable of carrying out bidirectional vehicle programming tasks from a remote location.
U.S. Patent Application Pub. No. 2005/0251304 to Cancellara, et. al. describes a system for performing both local and remote vehicle diagnostics, comprising a vehicle communications unit that acts as an intelligent interface to a vehicle to which it is connected and that is capable of performing autonomous vehicle diagnostics and communication functions. The system in Cancellara is designed only to provide for remote diagnostics, and does not describe a system and method for programming a vehicle. Moreover, Cancellara contemplates real-time diagnostics, i.e. “reading,” of a vehicle in operation, and not programming or manipulation of vehicle sub-systems.
U.S. Pat. No. 7,532,962 to Lowrey et. al. describes a system for monitoring a vehicle's operational characteristics having a wireless appliance in contact with an in-vehicle computer having a data-collection component that supports communications software that collects diagnostic data from the computer, and a data-transmission component in communication with the data-collection component, configured to transmit an outgoing data packet comprising the diagnostic data over a network and receive over the same network an incoming data packet that modifies the communication software. Lowrey, like much of the prior art, provides for a system for carrying out diagnostics of a vehicle's operational characteristics, but does not provide a system or method for remote programming of a vehicle.
U.S. Patent Application Pub. No. 2009/0265055 to Gillies describes a hand-held interface device configured to wirelessly communicate with a wireless OBD device in a vehicle to be repaired. A network access point and other wireless devices may be used to access vehicle information, repair instruction, diagnostic information research information, remote expert guidance, remote databases and applications, and other repair and diagnosis information from the interface device. The system in Gillies essentially captures vehicle information, relays the information to a server, wherein the server provides assistance information to a technician based on the vehicle information. The system, however, is not capable of providing remote programming to the vehicle from the server.
U.S. Pat. No. 7,584,030 to Graham describes releasable connectors with a wireless connection between automotive test equipment and a vehicle's OBD computer wherein the data link cable is replaced, using two connectors which have been pre-programmed to communicate with each other. The device in Graham concerns local wireless communication between the vehicle's OBD and a scan tool through a wireless link established by the device. Graham does not contemplate remote transmission of programming data over a data network, nor does it contemplate remote programming of the vehicle over that network.
Accordingly, there is a need in the art for a system and method that allows a technician to service and program a vehicle, through its ODB interface, from a remote location. There is a further need in the art for a system and method for programming a vehicle that does not require a shop or garage to purchase numerous expensive scan tools for each specific vehicle make and/or model. There is a further need in the art for a system and method of programming a vehicle from a remote call center that has the capabilities to program a wide variety of vehicles implementing a wide variety of OBD communication protocols. There is a further need in the art for a system and method of programming a vehicle from a remote call center that has the capabilities of always having the most recent scan tool software for a wide variety of vehicle manufactures and model years. These and other objectives of the various embodiments of the present invention will become readily apparent in the following specification and appended claims.